My app's crash numbers in App Store Connect's analytics are higher than I'd like, but I'm having trouble figuring out where they're coming from. In Xcode's Organizer, I see very low numbers of foreground crashes, and 95% of my background terminations are "System Pressure." So I have some questions about what's included in App Store Connect's numbers and correlating them with other signals: Do they include background terminations, or only foreground terminations? If they do include background terminations, do they include "File Lock" terminations (which I think largely means 0xdead10cc)? If they do include background terminations, do they include System Pressure terminations? Are all the crashes included in App Store Connect's numbers also delivered to MetricKit as crash diagnostics? Is there documentation on what "System Pressure" terminations are? My understanding is that it's when the system kills my app to free up resources.

I'm having trouble knowing whether my app is in good shape for battery usage by looking at the Battery Usage pane in Xcode's Organizer. I have some questions: At the top under "On-Screen Battery Usage", it says "Normalized to the usage of the most recent version when unplugged (x minutes / day)". Is the number there represented by "x" how long users tend to have my app open per day? When looking at the colored segments of the usage, I'm showing "Display" as 85% or more of the area. Is that just the cost of keeping the display turned on? Does it go up or down based on things like animations, displaying complex images, etc? It would be great to have an example of some apps of different types that are good "battery usage" citizens and what their battery usage looks like on this screen.

I've gotten diagnostics from a couple of my users experiencing a rare issue. The logs in the diagnostics clearly show that the view controller where the issue occurs gets viewDidLoad called twice, and then does not get viewWillAppear or viewDidAppear. This triggers a bug for me because the view controller loads the data it's meant to display in viewWillAppear. I can work around this by changing my data loading logic, but I'd like to know what the underlying issue is. Can anyone point me to some possible ways I could be triggering this weird UIKit behavior?

I've got a note editor view in my app that's built around a UITextView. At the top of the text view, it displays some metadata about the note, like location of the note (it's an e-reader app - think highlighting text and adding a note to it). I want this metadata to be able to scroll out of view if you scroll down in the text view. But it shouldn't simply be text in the text view - it's a UIView that takes the full width of the text view, with some UILabels in it. The height is on the order of 60 points tall. What's the best way to achieve this? Should the view that contains the labels be in a text attachment? Or should it be a subview of the UITextView? Or should I do something custom like make it a subview of the view that contains the UITextView and watch the UITextView's scroll position and apply a transform to move it to match?

I wrote a python script MXSymbolicate to symbolicate crash reports produced by MetricKit. To symbolicate a given frame, it needs the symbol file for that frame's library. For system libraries, my system only has the requisite files on disk if I've plugged an iOS device of that type at that iOS version into my computer at some point (I assume these symbol files from the device are generated by Xcode when it's preparing to debug on a new device). All these different versions of the symbol files take up a fair bit of space on my machine over time, and it means the symbolication process isn't very portable. Is there a better way to get ahold of symbol files for system libraries? Or is the expectation that we (as third party developers) only symbolicate the frames from our own apps?

My app has a meaningful number of 0xdead10cc terminations because it deals with sqlite files in a shared app container. Are there any tips to diagnose them or track down which files are most often held open? Are they delivered to MetricKit as crash diagnostics? They're hard to identify in the Xcode organizer - I have to right-click on a suspect, Show in Finder, Show Package Contents, navigate into the proper sub-folder for my filter, then into the Logs subfolder, and look through the raw crash reports. And these crash reports don't identify the file that the lock is held open to, and they don't identify the correct culprit thread. Not all of them even show any of my code doing file IO. FB12292887

See existing post here: https://developer.apple.com/forums/thread/803378 When I add a UIScrollEdgeElementContainerInteraction to a view at the top of a scroll view, the blur effect doesn't always fill the full bounds of the view. The behavior changed a bit from 26.0 to 26.1 and then again in 27.0 seed 1. It depends on what subviews are there, and particularly (at least between 26.1 and 26.5) if there's a UIVisualEffectView with a glass effect. FB20756572

I've got an iOS app with a custom top toolbar view that uses a UIScrollEdgeElementContainerInteraction to achieve the iOS 26 progressive blur background. It's over top of a web view, and I've set the top edge effect style on its scroll view to .hard so the toolbar's edges are more defined. I'm noticing that the blur doesn't extend fully to the bottom edge of the toolbar, and I'm curious to know if this is a bug or expected behavior. If the latter, what exactly are the details of what's expected? What determines the bottom extent of the blur? I've got this result in a sample project on iOS 26.0. The white border is the label, and the red border is the title bar view itself. Note that the Daring Fireball logo visible inside the bounds of the bar view, and is cut off at the bottom edge of the label. This is the code from the demo app that produced the screenshot. let config = WKWebViewConfiguration() let webView = WKWebView(frame: .zero, configuration: config) self.view.addSubview(webView) webView.translatesAutoresizingMaskIntoConstraints = false webView.topAnchor.constraint(equalTo: self.view.topAnchor).isActive = true; webView.bottomAnchor.constraint(equalTo: self.view.bottomAnchor).isActive = true; webView.leftAnchor.constraint(equalTo: self.view.leftAnchor).isActive = true; webView.rightAnchor.constraint(equalTo: self.view.rightAnchor).isActive = true; webView.scrollView.topEdgeEffect.style = .hard webView.load(URLRequest(url: URL(string: "https://daringfireball.net")!)) let barView = UIView() self.view.addSubview(barView) barView.translatesAutoresizingMaskIntoConstraints = false barView.topAnchor.constraint(equalTo: self.view.topAnchor).isActive = true; barView.leftAnchor.constraint(equalTo: self.view.leftAnchor).isActive = true barView.rightAnchor.constraint(equalTo: self.view.rightAnchor).isActive = true let edgeEffect = UIScrollEdgeElementContainerInteraction() edgeEffect.scrollView = webView.scrollView edgeEffect.edge = .top barView.addInteraction(edgeEffect) barView.layer.borderColor = UIColor.red.cgColor barView.layer.borderWidth = 1 let titleLabel = UILabel() barView.addSubview(titleLabel) titleLabel.translatesAutoresizingMaskIntoConstraints = false titleLabel.leftAnchor.constraint(equalTo: barView.leftAnchor).isActive = true titleLabel.rightAnchor.constraint(equalTo: barView.rightAnchor).isActive = true titleLabel.bottomAnchor.constraint(equalTo: barView.bottomAnchor, constant: -20).isActive = true titleLabel.topAnchor.constraint(equalTo: barView.safeAreaLayoutGuide.topAnchor, constant: 8).isActive = true titleLabel.textAlignment = .center titleLabel.text = "Title Here" titleLabel.layer.borderColor = UIColor.green.cgColor titleLabel.layer.borderWidth = 1

I wrote a python script called MXSymbolicate (https://github.com/OliveTreeBible/MXSymbolicate) to symbolicate the crash reports produced by the old version of MetricKit. The new MetricKit in the '27 releases appears to be basically the same data but in type-safe form, with the addition of state tracking. Notably, the new CrashReportExtension API seems to include the ability to symbolicate a crash stack on-device, but it looks like the CallStackTree type is still just binary names and frame offsets and such - no symbol names. Should I keep symbolicating crash reports from the new MetricKit APIs the same way I did the old ones? Or is the expectation that I should use the CrashReportExtension system for symbolicated crashes, and use the MetricKit crash reports for other purposes, like state tracking?

There seems to be a regression in the behavior of UIScrollEdgeElementContainerInteraction on iOS 26.1 when it's over a WKWebView. If the web view's scroll view's topEdgeEffect.style is changed to .hard and then back to .soft, it will stop tracking the color of the content underneath it and use the wrong-mix in color in its blur. I've filed this as FB20655398. Here's some sample code to illustrate the issue. The test.html file being loaded is just a bunch of div elements with lorem ipsum. private var webView: WKWebView? = nil override func viewDidLoad() { super.viewDidLoad() let config = WKWebViewConfiguration() let webView = WKWebView(frame: .zero, configuration: config) webView.navigationDelegate = self self.view.addSubview(webView) webView.autoPinEdgesToSuperviewEdges() webView.isInspectable = true self.webView = webView let url = Bundle.main.url(forResource: "test", withExtension: "html")! webView.loadFileURL(url, allowingReadAccessTo: Bundle.main.bundleURL) let blurView = UIView() self.view.addSubview(blurView) blurView.autoPinEdgesToSuperviewEdges(with: .zero, excludingEdge: .bottom) let label = UILabel() label.text = "This is a title bar" blurView.addSubview(label) label.autoAlignAxis(toSuperviewAxis: .vertical) label.autoPinEdge(toSuperviewEdge: .bottom, withInset: 8) label.autoPinEdge(toSuperviewSafeArea: .top, withInset: 8) let interaction = UIScrollEdgeElementContainerInteraction() interaction.scrollView = webView.scrollView interaction.edge = .top blurView.addInteraction(interaction) self.webView?.scrollView.topEdgeEffect.style = .hard DispatchQueue.main.asyncAfterUnsafe(deadline: .now() + .seconds(2)) { self.webView?.scrollView.topEdgeEffect.style = .soft } registerForTraitChanges([UITraitUserInterfaceStyle.self]) { (self: Self, previousTraitCollection: UITraitCollection) in self._updateWebViewColors() } } private func _updateWebViewColors() { let dark = self.traitCollection.userInterfaceStyle == .dark let text = dark ? "#FFFFFF" : "#000000" let bg = dark ? "#000000" : "#FFFFFF" let js = "document.body.style.color = '\(text)';\ndocument.body.style.backgroundColor = '\(bg)';" self.webView?.evaluateJavaScript(js) { res, err in if let err { print("JS error: \(err)") } } } If you run that, then change the system them to dark mode, you get this. Has anyone else seen this before? Know how to work around it?

The Crashes report in App Store Connect Analytics for my app is showing unexpectedly high crash rates, well over 2,000 per day (among roughly 150k active users per day). But I'm having trouble correlating this with other sources of stability reports: Firebase Crashlytics shows about 100 crashes per day over the last 90 days In the Xcode organizer, under “On-Screen Terminations” I see “Insufficient usage data available” which I take to mean very low numbers In the Xcode organizer, under "Background Terminations" it shows a little over 2 terminations per day, and well over 95% of those are "System Pressure" In the actual crash reports section of the Organizer, I have a little over 6,000 devices in the last two weeks encountering an issue that I think is 0xdead10cc, which I think would show up under Background Terminations as File Lock. As a side note, triaging these 0xdead10cc issues in the Organizer is a pain - see FB12292887. My main question here is what is included in App Store Connect's crash numbers. Do they include background terminations, especially "System Pressure"? Is there a way for me to get more information on the distribution of termination / crash types in those numbers? My understanding of System Pressure terminations is that it's when the system has to kill my app in the background to free up resources for other things, especially an app in the foreground, and it's not a "crash" properly speaking, although I might be able to make them less frequent if I reduce my memory usage. Am I incorrect in this? Notably, "System Pressure" is conspicuously not defined in the "Reducing Terminations in Your App" documentation under "Background termination reasons". https://developer.apple.com/documentation/xcode/reduce-terminations-in-your-app

I have a Catalyst app that uses popovers frequently, and I'd love to have them stay active when the app loses focus. It appears this is controlled in a native AppKit app via NSPopover.Behavior. Is this functionality exposed somewhere in Catalyst?

I've got a Catalyst app that exposes some custom context menu items via the buildMenu API. When it runs on Tahoe, there's some weirdness with how the images in the menu items are sized. See attached screenshot below. The three items on the bottom are using SF Symbols for their images, and the rest are using custom images from an asset catalog. Is this a bug in Tahoe 26.0? Or should I be resizing my images before giving them to UIAction? If the latter, what should the size be, and is this documented somewhere or available from an API?

In the WWDC 2025 session "Build a UIKit app with the with the new design", at the 23:22 mark, the presenter says: And finally, when you no longer need the glass on screen animate it out by setting the effect to nil. The video shows a UIVisualEffectView whose effect is set to a UIGlassEffect animating away as its effect is set to nil. But when I do this in my app (or a sample app), setting effect to nil does not remove the glass appearance. Is this expected? Is the video out of date? Or is this a bug?

In iOS 26 beta 3, it was possible to have a UIScrollEdgeElementContainerInteraction work with a WKWebView's scroll view. But it stopped working in beta 4, and is still broken in beta 5 today. Is this expected? Or is this a bug that will be fixed before public release? Filed as FB19386650 with a trivial sample app.